SOLID, ActivityPub, Bluesky/AT, Matrix... on ne compte plus les projets réinventant une manière de faire du "fédéré" ou du "social".

Pour permettre d'universaliser les échanges, chez Vignette, nous plaçons le web (HTTP) au centre.

💡 Toutes les interactions sociales au sein de Vignette fonctionnent déjà sur un modèle simple uniquement basé sur HTTP et créé de manière empirique. Vignette, c'est la preuve que ce modèle fonctionne.

HTTP : le protocole universel, mais limité

HTTP est le cœur du Web : c’est un protocole client–serveur, simple et robuste, qui permet de :

demander une ressource (GET),
en créer une (POST),
la modifier (PUT, PATCH),
la supprimer (DELETE).

Mais HTTP, seul, ne définit aucune logique ou sémantique "sociale".

Autrement dit :

HTTP transporte des données — il ne décrit pas les relations entre entités ni la manière de synchroniser des graphes distribués.

Pourquoi de nouveaux protocoles ont émergés ?

ActivityPub répond à un besoin de fédération sociale :

définir un langage commun ("Alice suit Bob", "Bob aime ce post")
permettre à différents serveurs (instances) de se parler sans dépendre d’un serveur central
gérer des relations d’acteurs, pas seulement des documents
ActivityPub s’appuie sur HTTP + JSON-LD, mais ajoute une couche de sémantique sociale et de fédération :

HTTP → transporte les messages

ActivityPub → définit ce que ces messages signifient et comment les synchroniser entre acteurs

Solid répond à un besoin de souveraineté des données :

séparer l’application (ex : ton carnet d’adresses) du stockage (ton “pod” personnel)
définir comment une application accède à tes données via des permissions standardisées
baser l’interopérabilité sur Linked Data et identité Web (WebID)

Là encore, Solid ne remplace pas HTTP : il le structure pour gérer la découverte, l’accès et le contrôle des données de façon uniforme.

Pourquoi on n’a pas “simplement étendu HTTP” ?

Parce qu’HTTP est volontairement :

agnostique au contexte (il ne sait pas ce qu’est un “post”, un “commentaire”, ou une “autorisation”)
stateless (chaque requête est indépendante)
et non normative sur les relations entre serveurs (il n’existe pas de standard HTTP pour dire “je suis abonné à toi”)

Les créateurs du Web ont toujours voulu que HTTP reste un transport universel et que les relations sémantiques soient décrites au-dessus, via RDF, JSON-LD, ActivityStreams, etc.

Le revers : la complexité s’accumule et les besoins en ressources explosent

Le problème aujourd’hui, c’est que :

Chaque projet (Solid, ActivityPub, Bluesky/AT, Matrix…) réinvente sa propre manière de faire du “fédéré” ou du “social”.
On superpose des couches de sémantique, d’identité, d’autorisation qui auraient pu, en théorie, être décrites directement avec HTTP et une convention claire.
Ces modèles ont un niveau élevé de redondance réseau par la fédération et le fan-out

Résultat : Le Web se refragmente autour de protocoles “interopérables” qui ne le sont pas nécessairement entre eux.

Proposition : un “HTTP social” minimaliste

Et si on arrêtait de créer des méta-protocoles et qu’on définissait simplement, via HTTP, des conventions standardisées pour le suivi, les publications, les permissions, etc. ?

Pour nous, le futur du Web éthique et sobre passera non pas par de nouveaux protocoles mais par une redécouverte du potentiel d'HTTP bien utilisé.

Autrement dit : faire du social décentralisé sans réinventer la roue, simplement en structurant autour d'HTTP pour obtenir un Web social qui privilégie la sobriété.

Nous présentons sommairement ici les idées que nous avons en tête pour un modèle de “HTTP social minimaliste et décentralisé”, pensé pour être sobre, compréhensible, interopérable et évolutif, uniquement avec :

HTTP(S) pour le transport,
JSON pour les données,
et des conventions claires d’URI et de codes de statut HTTP.

💡 On ne crée aucun nouveau protocole, on définit simplement une grammaire commune d’usage d'HTTP.

Modèle de base : “Chaque utilisateur est une ressource HTTP”

Un exemple d'interaction avec un utilisateur inconnu :

GET sur son URL (/.well-known/social.json ou son profil)
Obtention des routes disponibles : follow, post, like, etc.
Interaction directe avec les endpoints HTTP.

Aucune magie : juste des conventions et de l'auto découverte, comme pour les robots.txt ou sitemap.xml, mais sociaux.

Authentification, autorisations et sécurité

Les interactions peuvent être faites avec ou sans compte utilisateur, comme le web

Pour les interactions authentifiées, l'utilisation de Token Web standard sur l'instance porteuse du compte (JWT)

L’idée : ne pas réinventer OAuth ou WebID — utiliser les standards déjà déployés.

Pour les interactions authentifiées mais vers des ressources externes à l'instance d'authentification : identification simple de l'intervenant (ressource URL d'origine),

Pour les interactions non authentifiées :

modération à priori / rate limiter / blacklisting...

Exemple concret d’échange

Alice suit Bob : POST https://vignette.eco/{bobID}/api/follow+{alice URL}
Bob publie un post : POST https://vignette.eco/{bobID}/api/post → tous ses abonnés reçoivent le post lorsqu'ils se connectent (fan-out on read, pull model)
Alice commente : POST https://vignette.eco/{bobID}/api/comment+{alice URL + postID}
Bob écris un message à Alice : POST https://{alice URL}/{aliceID}/api/message
etc...

Chaque action est un échange HTTP standard, auditable, compréhensible, testable avec curl.

Chaque racine d'URL est vue comme un profile / un compte / un site web (c'est déjà le cas pour tous les sites réalisés avec Vignette)

Le serveur publie le contenu une seule fois, accessible via une URL publique.

Les autres serveurs viennent le lire lorsqu’ils en ont besoin (ex : quand un utilisateur consulte son fil).

Avantages de ce modèle

🟢Simplicité Très élevée (HTTP + JSON)

🟢Interopérabilité native (c’est du web pur)

🟢Consommation énergétique faible (moins de couches, pas de duplication, pas de trafic inutile)

🟢Courbe d’apprentissage Simple pour devs web

🟢Adoption possible rapide (API REST existantes)

Environnement et sobriété

Pas de duplication : le post existe chez l’auteur, les autres y accèdent par lien, pas par copie.
HTTP reste cachable, compressible et CDN-friendly.
Peut-être hébergé sur des petits serveurs partagés sans charge excessive ou mutualisé afin de réduire encore l'empreinte.

En résumé

Le “HTTP social minimaliste” propose un retour au Web originel :

Un utilisateur, un document, un post, une interaction sociale, etc... est une requête HTTP.
Pas besoin de protocole nouveau, juste de conventions communes.
Priorité à la légèreté et la sobriété, certaines ressources ne sont pas toujours accessibles car non répliquées (downtime, etc.)

Ce modèle serait à la fois :

écologiquement sobre,
interopérable nativement,
compréhensible pour tout développeur Web,
et résilient, car il repose sur les bases même du web.

Et vous, que pensez-vous du web social universel et de cette proposition ? N'hésitez pas à nous donner votre point de vue dans les commentaires ci-dessous. 🙏